Brett Frost
Caldari
Frost Enterprises
   |
Posted - 2009.05.14 19:56:00 -
[1]
 Originally by: Justar Geban
And, to pull the extra info on it wouldn't be just one byte - you'd have to pull the whole record. 'Cause guess what? Unless you are going to make a table *just* for BP's that only contains whether they are or are not originals, then the database hit to find out what a particular item's attributes are is going to read the whole record for that item, even if all you ask for is "is_this_original".
Now, does this make it more challenging for players? Yup. But you know what? The smart developers on here would do it exactly the same way given the same constraints. 
There are some obvious possibilities for differentiating between originals and copies without expensive queries.
The first is to add functionality to a column already present. There may already be a column containing flags that indicate the item's state. Adding another flag would only increase column size if each bit in the column were already assigned.
The second is to add such a column to the table. In this case a simple true/false value will suffice so a one byte column could be added. It could be used for several other flags as well since each flag would only need to take up one bit.
The third is to make copies a different base item than originals. This would probably require some additional code and quality assurance and would almost certainly require an extended downtime to convert existing blueprints. I regard this as generally less desirable than the first two given that a substantial portion of existing code is based on originals and copies being of the same base type.
I think it is highly likely that the table for hangar contents already has flags that are used for locking and to indicate if an item is currently being used in research or manufacture. However, the table for ship contents may not be the same table and therefore may not have a column for flags. Even if it doesn't, it may still have a column that doesn't apply to blueprints in any meaningful way and could be used for that purpose. Either way, a lookup is only required when the item is added to the table from a table that does not already differentiate in some way between originals and copies. That situation would be rare and probably already requires a lookup.
But why stop with just differentiating between originals and copies? There are several other pieces of information that would be extremely useful to cache in inventory tables. Adding three columns to the inventory tables would greatly enhance the user interface and probably only increase memory usage slightly. For blueprints the columns would be used for ME, PE, and remaining runs. That's information that I'd love to be able to see without checking each individual blueprint. For modules, I really want to be able to sort by meta level, and while not as important, it would be useful to see if they were damaged without having to check each one, so the other two could be used for current and maximum condition. That solves the scanner and kill mail issues for copies while also making it much easier to work with loot as well as perform research and manufacture. Unless adding 4-6 bytes per inventory record significantly impacted performance, this would be my preferred method.
Maybe a smart developer figures out how to accomplish something within constraints instead of just finding reasons not to do it? 
|